QWhat is the correct way to support EPS files using QuickDraw GX? Converting the QuickDraw preview into a GX shape and attaching a tag containing the PostScript code looks OK, but results in a vertically flipped PostScript image when printed. This is presumably because of the difference in orientation between GX and PostScript. Is it necessary to modify the PostScript code to solve this problem?
A It's true that when using PostScript synonyms, you need to account for the QD coordinate space. QD defines 0,0 as the top-left corner of the page, while PostScript defines 0,0 as the bottom-left coordinate. There is a small note on page 4-13 of the 'Quickdraw GX Printing' manual that mentions this.
There are many ways to handle this. One method is to use translate and scale to switch the coordinate system back. If, for example, the page is 760 pixels tall, you could use:
0 760 translate 1 -1 scale newpathto translate 0,0 back to the bottom left corner of the page. The rest of your PostScript code can then be sent as-is. Be sure to undo the effects of the translate and scale operations before attempting to draw any GX objects, or they will be upside-down as well.
QThe method you suggested is a fine way of supporting EPS in QuickDraw GX for many applications, assuming that they do not allow users to export the EPS. However, we need to support EPS as a position-independent shape (as part of a flattened picture shape). Since the method below relies on knowledge of the page height, it does not work for exchanging data between applications (for example, 'qdgx' clipboard and file formats).
I tried to enclose the EPS preview shape within a picture shape. The EPS synonym tag was attached to the picture shape, and a vertical reflection mapping was applied both to the preview shape and the picture shape itself. The idea was that the PostScript would be reflected once vertically (and thus print correctly) while the enclosed preview shape would be reflected twice vertically (and thus display correctly). Unfortunately, the PostScript did not print in the correct place, while the preview shape displayed correctly, but glacially. I'd appreciate any suggestions as to how to handle this in a position-independent manner.
A We've provided a function called EPStoShape that is an example of how to encapsulate your EPS into a GX shape. This sample is very simple, and it needs to be extended for use in a real application.
There are two cases that the sample code cannot handle:
1. With large EPS files, the EPStoShape routine reads the entire EPS file into a single handle, which is added to the shape as a 'post' collection. This works fine for small sample files, but to support larger EPS files, you should modify this routine to read the file in sections, adding mutliple, smaller collections to the shape. This reduces the memory requirements at print time.
2. The EPStoShape function looks for the %%BoundingBox comment in the EPS file to determine the size of the document/shape. This comment is usually found just before the actual document data, and it is followed by 4 integers representing the top,left,bottom,right of the bounding box. However, to make writing EPS files easier, the format of this comment was extended. Now, do the following:
%% BoundingBox: (atend)
<Actual Document Data>
%% BoundingBox: 0 0 10 10
In this case, the '(atend)' tells the reader that the actual bounding box can be found at-end of document data. The EPStoShape function assumes that the first BoundingBox comment has the four coordinates and generates bogus PostScript code if the (atend) keyword is found instead. To use this routine in your application, you should modify it to check for the (atend) construct and to look for the second BoundingBox comment, if it is found.
Both of these modifications should be easy to implement.